<?php
/**
 * <https://y.st./>
 * Copyright © 2019 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Learning Journal',
	'<{subtitle}>' => 'CS 4406: Computer Graphics',
	'<{copyright year}>' => '2019',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<section id="Unit1">
	<h2>Unit 1</h2>
	<p>
		The reading assignment for the week was as follows:
	</p>
	<ul>
		<li>
			<a href="https://math.hws.edu/graphicsbook/c1/index.html">Introduction to Computer Graphics, Chapter 1 -- Introduction</a>
		</li>
		<li>
			<a href="https://math.hws.edu/graphicsbook/c5/index.html">Introduction to Computer Graphics, Chapter 5 -- Three.js: A 3D Scene Graph API</a>
		</li>
		<li>
			<a href="https://people.csail.mit.edu/fredo/Depiction/1_Introduction/reviewGraphics.pdf">A Short Review of Computer Graphics.PDF - reviewGraphics.pdf</a>
		</li>
		<li>
			<a href="https://www.cs.csustan.edu/~rsc/NSF/Notes.pdf">Notes.pdf</a>: Chapter 0 and Chapter 1
		</li>
	</ul>
	<p>
		Seeing that the Introduction to Computer Graphics textbook focusses on {$a['3D']} graphics piqued my interest.
		When I signed up for this course, I was hoping to learn how to better create {$a['2D']} graphics, a skill I&apos;d use on my website, for creating game graphics, and perhaps more.
		Working with {$a['3D']} graphics should be pretty interesting though.
		In the end, as the textbook says, the end result of {$a['3D']} graphics editing is a {$a['2D']} image.
		I didn&apos;t think I could use that sort of thing much in the type of game I need images for, but I should be able to get even better-looking Web graphics using {$a['3D']} methods.
		As I read on, I found we were discussing terminology I&apos;d seen in Blender when trying to create a {$a['3D']} model though.
		I&apos;m starting to get into some basic modelling in the game I work with, so what we learn in this course may help with my game graphics after all, just not the part I&apos;d thought about as graphics.
	</p>
	<p>
		The term &quot;frame buffer&quot; was new to me, but the concept wasn&apos;t.
		I was already aware that the colour values for the image on-screen was stored in some block of memory, and that changes made to that block of memory cause changes on the monitor without need to recalculate every single pixel.
		You can even see side effects of that system when things go wrong.
		For example, Firefox locks up on me sometimes.
		When it does, all Firefox windows stop calculating values for their pixels (aside from the pixels of the window border, which are handled by the window manager instead of Firefox itself), and these windows begin to capture the output of whatever was in their place previously.
		For example, if I minimise the window to reveal the windows behind it, then unminimise the malfunctioning Firefox window, the window boarder gets drawn, but the inner pixels of the window don&apos;t change, so I see a still frame of the windows that were behind the Firefox window before I brought it back up.
		Or I can drag a smaller window across the malfunctioning Firefox window and it&apos;ll leave a trail.
		All of this is because Firefox isn&apos;t updating the values in the frame buffer that it&apos;s responsible for, so those valuse remain at whatever another process last set them to.
	</p>
	<p>
		I was also aware of the term &quot;raster graphics&quot;, and know the difference between raster graphics and vector graphics, though I wasn&apos;t aware the term was a legacy term from the vacuum tube days.
		I&apos;ve never managed to figure out how to properly edit vector graphics in an editing program though.
		I manage to make use of the $a[GIMP] reasonably well, but I can&apos;t get the first shape into place in Inkscape.
		The best I&apos;ve managed to do is compose and edit the $a[XML] of $a[SVG] files in a code editor, using an image viewer to check the results so as to know what to adjust.
		It&apos;s a bit of a pain, actually.
		I was also already aware of the difference between lossy and lossless compression.
		I&apos;ve never liked the idea of lossy compression, but it does drastically cut down the file size of my photographs.
	</p>
	<p>
		On some level, I knew enough about {$a['3D']} graphics to know that they&apos;re created using {$a['2D']} shapes in a {$a['3D']} space.
		I knew they weren&apos;t generated using voxels, the {$a['3D']} equivalent of pixels.
		It hadn&apos;t occurred to me that this makes them very similar to vector graphics though.
		I have far too little experience with both vector graphics and {$a['3D']} graphics to have notice such a conclusion.
	</p>
	<p>
		The textbook explained that shaders are small programs sent to the $a[GPU], and that they don&apos;t always have anything to do with shading.
		That explains a lot in the game I work with.
		The developers added several features that they called shaders, but some of them can&apos;t even be remotely attached to the idea of shading.
		For example, one of them causes certain images to be displaced, and another couple case objects to move around visually.
		These features are probably implemented using $a[GPU] shaders, so the developers are calling them shaders.
	</p>
	<p>
		I couldn&apos;t follow a lot of what the material on <code>three.js</code> was saying.
		It was a bit above my head.
		One thing I did understand though was how the faces in a <code>three.js</code> model don&apos;t specify the coordinates of their vertices directly, but instead specify where those vertices lie in the vertex array.
		That seems rather useful.
		I mean, it obviously means more overhead, but it also means more consistency.
		If a vertex gets moved, all faces using that vertex are essentially automatically updated.
		Or more accurately, the faces don&apos;t even <strong>*need*</strong> to be updated.
	</p>
	<p>
		The short review of computer graphics claimed purple to be at (255, 0, 255).
		That is definitely not purple.
		That&apos;s pure magenta, one of the eight most extreme colours; the others being black, white, red, blue, green, yellow, and cyan.
		There&apos;s some variance as to where people draw the lines between colour labels, but there&apos;s no mistaking what colours are at positions with all colour channels each set to either zero or two fifty-five.
		If you&apos;re working with graphics, you should know these eight basic colours.
	</p>
	<p>
		At first, I liked how the textbook is sensible enough to start at the beginning when numbering its chapters; which is to say, it starts at chapter zero instead of just skipping over it like most books, textbook or otherwise.
		However, it seems to only even call it chapter zero in some contexts, and not label it as even being a chapter in others, such as the table of context.
		It&apos;s sort of treating zero as less than a number.
		That&apos;s a let-down.
	</p>
	<p>
		The {$a['3D']} eye coordinate system seems bizarre.
		If I&apos;m understanding it correctly, instead of moving the camera, you move everything <strong>*except*</strong> the camera as a way to simulate camera movement.
		That seems rather complicated compared to just moving one object, the camera itself.
	</p>
	<p>
		The concept of parallel and perspective viewing volumes is interesting.
		With how complicated {$a['3D']} graphics rendering seems to be, I hadn&apos;t even considered something as simple as parallel viewing volume.
		I just sort of assumed that you always had to calculate trajectories from objects to the viewing point, which makes the image more realistic, but also more complicated to produce.
		It seems that&apos;s actually optional though, and can be done depending on what sort of effect you&apos;re going for.
	</p>
	<p>
		The section on converting coordinates from the eye space to the display space was enlightening.
		It hadn&apos;t occurred to me that the eye space uses floats instead of integers for its coordinate system.
		I should have realised though.
		I really don&apos;t know how to make much work in Blender yet, but I&apos;ve worked with it a little bit.
		I managed to make a cube and get it properly sized and textured for what I needed.
		That&apos;s the extent of what I&apos;ve done in Blender.
		However, that little bit should have been enough to show me that the coordinate system used was in floats.
		I mean, I had to get the cube&apos;s side length to <code>1.28</code> before it came out right, and that&apos;s clearly not an integer.
		The eye space is an intermediate step between the world space and the {$a['2D']} image, so there&apos;s no reason for it to jump immediately to integer coordinates.
		If it did, it really wouldn&apos;t be any different than the final {$a['2D']} image&apos;s coordinate space and could simply be skipped.
	</p>
	<p>
		If we&apos;re going to be working the way the textbook describes, we&apos;ve going to be defining callbacks to do our work instead of doing it directly.
		I&apos;m well familiar with using callbacks, but it&apos;s surprising that we&apos;d be handling graphics this way, if this course is at all what I thought it was before I registered.
		I thought we were generating graphics, such as $a[PNG] files.
		If we&apos;re instead creating interactive scenes, that&apos;s an entirely different situation, though callbacks would certainly make the most sense in such an environment.
	</p>
	<p>
		I thought that transforming the world space to convert from world coordinates to eye coordinates would be very complex.
		The textbook did a great job of explaining just how simple the calculations are though.
		At least, when dealing with an orthographical view, these calculations are extremely simple.
		You just move the world using the reverse path in which you moved the eye, setting the eye back into the default position in the process (as moving the world moves the objects in the world, such as the eye itself).
		The world thus becomes eye-centric.
		Perspective views perform further calculations that are a little more complex.
		You basically divide a point&apos;s <var>x</var> and <var>y</var> values by their <var>z</var> value to find where on the {$a['2D']} image space they project to.
		It seems simple except when I try to think about it too hard, at which point I start looking for some complex way to determine which otherwise-visible points are ignored because they&apos;re obscured by closer points.
		The obvious answer though is to render everything, and when it comes to projecting to the {$a['2D']} space, only write the colour of the relevant pixel according to the point with the <var>z</var> value closest to zero.
		It&apos;s a bit difficult for me to keep in mind that you can compare all the objects; you don&apos;t have to take a pixel and use it to calculate the one and only object it can see, then deal exclusively with that object.
		Rendering isn&apos;t a lookup operation.
	</p>
	<p>
		I recently learned the term &quot;z-fighting&quot;, and immediately recognised the visual effect from a particular game I play sometimes.
		However, I&apos;d never given much thought as to exactly why it occurs.
		The textbook gave an excellent explanation though.
		Items occupying the same space have the same <var>z</var> value, so when <code>z</code> values are compared to see if the current object is the closest thing to the camera, the points on both objects, when the object is drawn, register as the closest and are able to draw to the pixel.
		Next time the other equally-close object is drawn, it overwrites the value set by the previously-writing object, and the value of the pixel flips back and forth.
		Very interesting.
		The textbook framed it as a rounding issue when converting from continuous numbers to integers, but I don&apos;t think that&apos;s actually all that relevant to the issue.
		First, two objects could share exactly the same continuous number coordinates and that same effect would occur, with or without rounding.
		And secondly, the computer representation of a float has precision limitations too; there&apos;s not just integer size limits.
		So even if numbers remained as floats and were used that way, z-fighting would still occur.
		The rounding certainly makes z-fighting more likely to occur though.
	</p>
	<p>
		Reading through the assignment notes for the week, they said that we&apos;d be working with <code>three.js</code> because it doesn&apos;t require C++ and because it uses JavaScript and JavaScript is a language we&apos;ve worked with previously in this school&apos;s computer science curriculum.
		Um.
		What?
		I don&apos;t remember writing a <strong>*single*</strong> line of JavaScript at this school!
		I <a href="https://y.st./en/coursework/">archive</a> all my coursework though, so I went back and checked for the presence of JavaScript.
		Sure enough, there wasn&apos;t a single JavaScript file and not a single assignment that related to JavaScript in any way.
		And for context, I&apos;ve taken <strong>*both*</strong> Web programming courses already.
		They covered $a[PHP], $a[XML], $a[CSS], and $a[HTML], but not JavaScript.
		JavaScript had <strong>*not*</strong> been a part of this school&apos;s curriculum!
		I think we discussed JavaScript one week in one of the courses, but we definitely didn&apos;t learn it.
		After writing my thoughts on that though, I went back to reading the notes, and noticed the exact wording used.
		JavaScript was one of the languages &quot;introduced&quot;, not one of the languages &quot;learned&quot;.
		Okay, the notes had me there.
		We&apos;d definitely had JavaScript introduced to us in the form of telling us it existed, we just weren&apos;t taught how to actually use it.
		Just like we were introduced to the fact that Perl is a language, but again, not actually taught to make use of that language.
	</p>
	<p>
		I know some JavaScript from my own experiments outside the school, though JavaScript is a language I&apos;m very weak in.
		With access to the Internet at my fingertips though, I&apos;ll be able to look up the functions I need to make it through the class, I think.
		As for C++, I&apos;ve been hoping that C++ would be taught in a course I&apos;ll take in the future, though this seems to confirm that it won&apos;t be.
		It doesn&apos;t seem to be taught at this school, which is disappointing.
	</p>
	<p>
		The notes also say to get the code for the assignment from the &quot;Development Environment link in the course page&quot;.
		No such link exists on the course page.
		I checked the syllabus too, and it&apos;s not there.
		I ended up giving up and checking the assignment page, which I&apos;d put my reading of on hold to read the notes, as the assignment page told me to read the notes.
		The code was there, as it should be, and not through some separate &quot;Development Environment&quot; link.
	</p>
	<p>
		This seems to be the harder of my two courses this term.
		Some of the material seems to be above my head.
		Hopefully I can pull it together and figure out the material.
		I&apos;d love to learn how to generate and render {$a['3D']} scenes like this.
		Honestly, I don&apos;t see this stuff applying to a job I&apos;d be interested in, but off the clock, this seems like I could do a lot of things with it.
		It might even help me contribute to a project I like called Minetest.
		It&apos;s a {$a['3D']} game in which the world is made up of giant cubes.
		It uses the Irrlicht engine, mentioned briefly in one of the tables presented in the reading material, and relies on code contributions from the community for its continued development.
		I&apos;d love to be a part of what makes Minetest so great.
		The textbook also mentioned Blender.
		If I could even learn to use Blender properly, I could improve the plug-ins I write for Minetest, even if I didn&apos;t have the skills to contribute to the Minetest engine itself.
		In any case, I feel like there&apos;s a lot I could get from this course if I can wrap my head around the material better.
	</p>
</section>
<section id="Unit2">
	<h2>Unit 2</h2>
	<p>
		This week&apos;s reading assignment was <a href="https://www.cs.csustan.edu/~rsc/NSF/Notes.pdf">Notes.pdf</a>, chapters two and three.
	</p>
	<p>
		The grading rubric for this week was bizarre.
		It had us grade last week&apos;s assignment based on the completely-different criteria laid out by this week&apos;s assignment instructions.
		The obvious choice was to give everyone a zero, as the criteria didn&apos;t fit what anyone actually did.
		It&apos;s a good thing this assignment isn&apos;t worth points.
		Or at least, it claimed last week not to be worth points, so hopefully, it isn&apos;t.
		However, it seems rather unfair to grade that way, so I instead gave everyone full credit with my notes explaining that the rubric given didn&apos;t match the assignment.
	</p>
	<p>
		The first student submitted the example code from the assignment.
		I considered doing this, but there were a couple reasons I didn&apos;t.
		One of those reasons being that we didn&apos;t actually modify the code in any way, which means that code wasn&apos;t our work; our work was to read the notes and try to understand them.
		Submitting the code wouldn&apos;t be an accurate representation of my efforts.
		The second student provided a screenshot of what they saw, which was interesting.
		It allowed me to verify that I wasn&apos;t the only one not seeing something similar to what the notes for the assignment showed in its included screenshot.
		Like what I saw, this student saw no distinction between the faces of the pseudo-sphere.
		The third student did what I did, and submitted their thoughts on the assignment.
		They kept it much more brief than I did; as I&apos;m sure you can see here, I tend to be very verbose.
		I tend to learn best when I&apos;m writing about what I&apos;m studying, and if I don&apos;t write enough, I tend not to learn as much.
	</p>
	<p>
		Most of this week&apos;s reading material was much easier to understand than last week&apos;s.
		A lot of it was stuff I already knew from mast experience, such as how transformations work on shapes in a coordinate space.
		One thing about the explanation of transformation order confused me.
		In the example $a[API] calls, three transformations are applied and then the geometry is set up.
		How can the geometry be set up last?
		Doesn&apos;t there need to be the base geometry before any transformations are applied so the transformations can have something to be applied to?
		Also, the textbook said that the transformations are applied in reverse order, because they&apos;re applied in terms of which transformation is &quot;nearest&quot; to the geometry.
		What I understood that to mean is that because the $a[API] call associated with the final transformation was closest to the $a[API] call setting up the geometry, it was the &quot;closest&quot; transformation to the geometry.
		That was the only thing that made sense in the context.
		Except that it didn&apos;t make sense.
		An $a[API] call can&apos;t be run on data that doesn&apos;t exist, then retroactively get applied when the data becomes available.
		That&apos;s not how operating on data works.
		You could set up a stack to push the operations onto so you could make it appear that that&apos;s the way operating on data works, and doing so would result in that reverse order behaviour, but that&apos;d be unnecessary overhead.
		I could only assume that I&apos;ve completely misunderstood what&apos;s going on.
		Later on, the textbook specifically said that transformations are applied in the order &quot;last-specified, first-applied&quot;.
		This pretty much means the stack theory isn&apos;t too far off.
		However, it still seems bizarre that you wouldn&apos;t code in the order you need things done.
		For some reason, the graphics $a[API] is having us code backwards.
		Is there any good reason for this?
		I have to assume that someone thought there was, and that someone knows a lot more about graphic rendering than I do.
		And then the textbook went back to calling it applying the transformation &quot;closest&quot; to the geometry again.
		Which still doesn&apos;t make any sense.
		$a[LIFO] is something I can understand and work with though.
	</p>
	<p>
		Soon, the textbook started comparing the transformations to a stack as well.
		But the context at that point was that previously-defined transformations affect later geometry.
		If you define a bunch of transformations, then define a cube to make use of those transformations, the cube will be transformed because everything is done in reverse order for whatever reason.
		But then, when you define an unrelated sphere, all the same transformations apply to the sphere as well.
		You don&apos;t define transformations that will apply to an object you need transformed.
		Oh no.
		That would actually be easy to work with, and we can&apos;t have that.
		Instead, you need to first transform the entire, empty scene, then throw objects into it ant they all get transformed the same way.
		Not going to work for you?
		In that case, you need to define the transformations for your first object, define the first object, undo the transformations, add new ones that apply to your second object, then define the second object.
		What a complete mess.
		What in the world were the people that came up with this system thinking!?
		I have to keep reminding myself that they must have known something I&apos;m not thinking of.
		I mean, there&apos;s obviously a lot they know that I don&apos;t, but there must be something huge I&apos;m missing if this is actually somehow a good system.
	</p>
	<p>
		The explanation as to why meshes are made out of triangles was enlightening.
		I&apos;d assumed it was a limitation of the graphics library.
		I figured it was easier for the developers of the library to disallow polygons with an arbitrary number of vertices.
		You can build other polygons out of triangles, so allowing only triangles is &quot;good enough&quot;.
		That&apos;s not actually the case at all though.
		If you have three or fewer points, there will always be at least one plane that they all lie on.
		If you add a fourth point though, it can be off-plane from the other planes, so the surface of the face it represents would be undefined.
		Limiting us to work with triangle prevents such undefined surfaces.
		There are ways around that issue without limiting sides.
		For example, you could change the format for specifying polygons, so the first parameter is the equation of a plane and the second parameter is the list of vertices in the order they connect.
		The vertices would be transformed from the {$a['2D']} space of the plane to the {$a['3D']} space of the world by the graphics library, but because they were originally defined in a {$a['2D']} space, you&apos;d have absolute certainty that they all lied on the same plain.
		What a nightmare though, both for the developers of the library and users of it!
		It would really complicate the format and make it harder to work with.
		Limiting faces to being triangular makes life easier for everyone involved.
	</p>
	<p>
		I wasn&apos;t clear on what normals are at first, either.
		The textbook says you might need them if your object needs to face a certain direction, but didn&apos;t tell what they actually are.
		From the context, I was guessing that they might be some angular offset used to shift all faces of a model by, but I really didn&apos;t know for sure.
		Much, <strong>*much*</strong> later, as in in another chapter even, the textbook actually told us what normals are.
		A normal is a vector that&apos;s perpendicular to its respective face.
		Was that so hard?
		Using terminology and then only later actually explaining it really makes it hard to learn.
		I spent much of the reading confused as to what normals even were, so I had no way to process much of what was said about them.
		I&apos;d go back and reread the chapters again, but there really isn&apos;t time in the week for that, so that information is just lost to me and I&apos;m probably going to end up struggling later.
		Some of what I need will likely be found through specific Web searches, but some of it likely won&apos;t be.
		And even if it all was all easy to find online, there&apos;s really no benefit in the textbook using unknown terminology long before explaining it.
		It didn&apos;t even take long to explain it when the book finally got to it (a single sentence, really), so it could easily be fit in before the first usage of the term.
	</p>
	<p>
		The textbook brought up another good reason graphics $a[API]s allow you to model things in their own space, then place them in the scene.
		It already mentioned object reuse last week.
		That reason alone is enough to warrant $a[API] options for the task.
		But then this week, it makes the claim that it&apos;s difficult to model things in the world at their intended locations.
		Boo hoo.
		You just need better graphics-editing tools, if you can&apos;t pull that off easily.
		But then it brings up that things need to move through the scene, if the work is animated.
		Modelling would be a nightmare if you had to adjust the coordinates of each vertex of the image every time the object as a whole moved.
		That&apos;s definitely a second good reason for providing the tools needed to model things in their own space.
	</p>
	<p>
		The textbook makes a great point about why models should usually be centred about the origin.
		When the section began, I actually started thinking about off-centre objects and how being off-centre would change the effects of scaling.
		I concluded that everything would be fine, as the distances between the surfaces would be the same, so the object would scale to the same.
		Mostly, I was write.
		However, the book pointed out that objects are scaled about the origin, so if an object is off-centre, scaling it will have the side effect of moving it through space.
		Well, I mean, the object is still technically located in the same spot, by the computer&apos;s perspective..
		However, the the place it <strong>*renders*</strong> will change.
		The computer sees the object as existing at the finite point we moved the origin of the object to, but what we perceive as the object gets moved out of place.
		I can see some use cases for off-centre origins though.
		For example, if a tree&apos;s origin was at the base of the model, scaling it wouldn&apos;t cause the tree&apos;s trunk to plunge into the ground (or jump up into the air) and need to be placed back on solid ground again.
		The textbook also mentions that rotating objects whose centre is at the origin is also easier because the object likewise doesn&apos;t move through space in unexpected ways.
		For most models, centring then at the origin really seems like the best option.
	</p>
	<p>
		The textbook explained why in most cases, you should scale, rotate, then translate an object.
		Other orders have less-intuitive and harder-to-work-with effects.
		If we pay attention here though, there&apos;s more we can pick up from the example of the distorted box: transformations are applied not based on an object&apos;s own coordinate space, but based on the world space the object resides in.
		We shouldn&apos;t, therefore, think about translations in the model&apos;s own space when we&apos;re trying to transform them in the world.
		We should think of them similarly to primitives we might have used in the world directly.
	</p>
	<p>
		The textbook brought up that because scaling is multiplication, reversing it is division.
		With that in mind, it continued, you can&apos;t undo a scale to zero.
		Huh.
		Right.
		Division by zero errors.
		I admit I hadn&apos;t thought of those, but not because I simply didn&apos;t think about division by zero.
		Instead, because I hadn&apos;t thought about <strong>*multiplication*</strong> by zero!
		In the real world, if you multiply something by zero, you have nothing.
		Nothing exists in two dimensions, so multiplying the width of something would result in having no object and no volume.
		In a computer representation though, <strong>*everything*</strong> is in two dimensions.
		The faces can be arranged at arbitrary angles in {$a['3D']}, but the faces themselves are two-dimensional, and the faces are the only things that actually exist in the scene.
		Scaling a dimension by zero simply crunches the face back into a two-dimensional orientation parallel with two of the axes; it doesn&apos;t make it disappear altogether.
		You could even scale all three dimensions by zero and get a face with all vertices existing at the same point in space.
	</p>
	<p>
		Later, the textbook finally explained what it meant by transformations being &quot;closer&quot; to the geometry.
		It meant that these transformations were nested deeper in a scene graph, closer to the node representing the relevant geometry.
		When the textbook first mentioned transformations being &quot;closer&quot; to the geometry, it provided no such explanation of what it was even talking about.
	</p>
	<p>
		The textbook mentions that you can&apos;t create a cube out of a single quad strip.
		This is very true, but I think it&apos;s worth briefly taking a look at why.
		Six connected squares could easily be folded into a cube, depending on how they are connected.
		In fact, each of those squares could be connected to no more than two other squares, creating a continual path of squares.
		Take four squares in a row, then attach a square above one end and one below the other.
		However, quad strips can&apos;t be defined that way.
		In a quad strip, the two vertices shared between a pair of adjacent squares can&apos;t be shared by any other square.
		In other words, you can&apos;t define three squares in the quad strip to share a single vertex, and a continual strip of squared that could fold to become the faces of a cube would have to have at least two vertices that were each shared by three squares.
	</p>
	<p>
		The textbook at first said that display lists were named unsigned numbers.
		Of course, I would try to begin naming lists from zero.
		I&apos;m a programmer.
		Programmers realise that zero is a valid number, and don&apos;t skip it when indexing or naming.
		A bit later though, the textbook reiterates, but this time says you need to use unsigned, <strong>*non-zero*</strong> integers.
		That makes a huge difference.
		I could have easily gotten stuck trying to debug for hours if using zero silently fails and the inability to use zero wasn&apos;t mentioned.
		Of course, I don&apos;t know if it silently fails or not.
		Maybe it halts the script and spews visible error messages telling you exactly what the problem is.
		We can always be hopeful that that&apos;s the sort of behaviour a library will have, so you&apos;re not left trying to debug simple problems without any clue as to what the problems actually <strong>*are*</strong>.
	</p>
	<p>
		The assignment for the week was a major headache.
		Whenever I try to run the code given to me by the university in my Web browser directly, no graphics are rendered and the Firebug console gives me the error message &quot;Access to restricted URI denied.&quot;.
		So I can&apos;t see what I&apos;m doing.
		Last week, the code ran just fine on the JSbin website.
		This week, it doesn&apos;t render there, either.
		I was going to have to work blind.
	</p>
	<p>
		I tried.
		I really tried.
		But I just can&apos;t work if I can&apos;t see.
		You should see me when I&apos;m coding.
		I often write small fragments at a time, then running my code to see if it did what I expected.
		Even for the most-basic stuff.
		And I often botch things pretty badly.
		But because I can <strong>*see*</strong> what&apos;s going on, I can correct it.
		I may not even understand what goes wrong right away, but I just keep adding output to the problem area until I find what output isn&apos;t as expected, and can fix it.
		But I can&apos;t do that if I can&apos;t see.
		And I have no idea what I&apos;m doing when it comes to WebGL, so I can&apos;t even assume I&apos;m coding things right and move on.
		I can&apos;t work blind.
	</p>
	<p>
		There was no time to ask for help.
		I&apos;d taken too long to read the textbook this week.
		The material is difficult to get through, and takes me forever.
		I needed to get my assignment done quickly in the remaining time, and if I waited for a response to my queries, the deadline would pass.
		I decided to try to figure out what script was misbehaving and causing that error message.
		I deleted all references to scripts aside from the main Firebug script, hoping to add them back, one by one, until Firebug complained again.
		However, Firebug didn&apos;t quit complaining, so it couldn&apos;t start again.
		The main Firebug script was trying to access some forbidden $a[URI]!
		I don&apos;t know what the problem is, but Firebug just isn&apos;t going to run locally, it seems, and I just don&apos;t get it.
	</p>
	<p>
		Next, I tried to figure out what was so magical about last week&apos;s code.
		Why did it run in JSbin when this week&apos;s code doesn&apos;t?
		The first step was to see if I could inject the code for the yellow triangle from the example that wouldn&apos;t run into the sphere code from last week that did run.
		I couldn&apos;t see the triangle.
		I assumed it was inside the sphere, or something.
		So I found the line that added the sphere to the scene and commented it out.
		The sphere was still created in the code, it just wasn&apos;t added to the scene and rendered.
		Success!
		I had a spinning, yellow triangle.
		Is the example code this week just broken?
		Perhaps it&apos;s just broken.
		But why?
		So I started comparing the two files to see what might be the problem.
	</p>
	<p>
		The first thing I noticed were the line endings.
		The rendering code used <code>\\n</code>, while the dysfunctional code was using <code>\\r\\n</code>.
		That shouldn&apos;t cause a problem in the rendering, but it was distracting, as it made every line in the editor change as I flipped between the two files.
		I couldn&apos;t see what had really changed.
		So I converted all the line endings to <code>\\n</code>.
		Next, I saw the dysfunctional code didn&apos;t have a <code>&lt;title/&gt;</code> element.
		That made the dysfunctional code technically invalid, but I didn&apos;t think JSbin would care enough to disable the output over it.
		And actually, the Firebug console was showing up anyway, proving that JSbin was in fact trying to properly set the JavaScript to run.
		Next, I saw ... the script tags were different.
		Last week&apos;s included JavaScript files were fewer in number and mostly hosted by my nemesis, CloudFlare.
		Actually, I&apos;m surprised those files actually work because of who&apos;s hosting them.
		This week&apos;s JavaScript files were greater in number and mostly hosted by the university.
		Could that be the problem?
		I swapped out the scripts, and found I was working with the wrong file: the one that wasn&apos;t supposed to render anything.
		The spinning triangle example, while still unable to render, actually does have a proper <code>&lt;title/&gt;</code> element.
		Also, most of the scripts are instead hosted on some website about healthy living that no longer exists, and thus can&apos;t serve the scripts.
		Bingo.
		I&apos;d found the problem.
		But also, why do all three of these files have different base environment scripts?
		I mean, two of these are even supposed to be the same assignment.
		Why would they have different environments?
		And on closer inspection, the two files that seemed to have a <code>&lt;title/&gt;</code> element actually have <strong>*two*</strong> <code>&lt;title/&gt;</code> elements, which is invalid, while the file I thought didn&apos;t have any actually had one.
		Whoever wrote these files didn&apos;t know what they were doing.
	</p>
	<p>
		With the reason for the yellow triangle file not working seemingly found, and having nothing to do with the template file, I tried injecting the yellow triangle into the template file.
		Still no rendering.
		But when I next completely replaced the sphere&apos;s geometry in last week&apos;s code, the yellow triangle rendered just fine.
		Next, I tried replacing the linked scripts in both files that wouldn&apos;t render with links to the scripts from the working file.
		I thought for sure that that&apos;d work, but it didn&apos;t.
		It was time to look for more file differences.
		This time, I found that the broken code was using the <code>Detector.webgl</code> property to conditionally choose a renderer, while the working code did not.
		So I deleted the conditional.
		That didn&apos;t fix anything.
		The hight and width of the window were set differently as well, and while I didn&apos;t think it would change anything, I tried setting them according to the working file&apos;s values just to rule that out.
		Sure enough, no effect.
	</p>
	<p>
		Next, I came across the line that statically set the renderer in the working file.
		That was missing from the broken code, because the broken code was using the conditional statement instead to set the renderer.
		Copying over the renderer-defining line, I finally got the example code to work.
		Except ... the triangle was bigger now, and no longer spun.
		The spinning and apparently some zooming out had come from elsewhere in the sphere code.
		With the rendering now working, it was time to undo all of my changes, then redo the renderer fix, to reset me back to a clean starting place.
		The code went back to not working, but after replacing the <code>&lt;script/&gt;</code> tags again, everything went back to rendering properly.
		Next, I tried only fixing the renderer in the template file we were given, as it used scripts from the university&apos;s website, but that wouldn&apos;t render either, and I needed to swap out the <code>&lt;script/&gt;</code> tags there, too.
		It seems the university is no longer hosting the required scripts, or something.
		Long story short, the files this week both use code that doesn&apos;t work and rely on scripts that aren&apos;t there any more.
	</p>
	<p>
		After debugging all that, I started trying to build my solution, and noticed that my spell-checker had detected a misspelled word in a comment, so I read the comment while I was fixing that.
		The comment told me to disable the detector.
		If it needed to be disabled, why was it included?
		But also, disabling that hadn&apos;t been the only thing needed.
		I&apos;d needed to replace the <code>&lt;script/&gt;</code> tags.
	</p>
	<p>
		With my template now working, I copied over the triangle code, then painted the triangle blue.
		It disappeared though!
		I thought I was dealing with another bug, and after being unable to find it, I just copied over the triangle again, overwriting the painted one.
		It rendered.
		So I painted it blue again.
		And it disappeared!
		I spotted an ambient light that had been added to the scene.
		It had no blue component.
		If I&apos;d chosen to make the triangle red, as the assignment allows our rotating square to be either red or blue, it would have no doubt showed up in the light, but a blue object absorbs red and green light, reflecting only blue.
		And there was no blue to reflect.
		I changed the ambient light to output white light, and sure enough, the triangle regained visibility.
		Perfect.
	</p>
	<p>
		Next, I tried adding another vertex to the triangle.
		It&apos;d be horribly unsquare, but I needed to see if I could simply add vertices.
		It seems I could not.
		I added two more to see if it&apos;d add a second triangle.
		When I saw it did nothing, I was about to set the camera to zoom out a bit and see if the vertices were off-screen, I remembered I hadn&apos;t added edges or faces.
		Of course they weren&apos;t rendering.
		From here, I decided to just scrap the triangle and try out a triangle strip.
		I couldn&apos;t figure out how to do that though.
		After some unsuccessful Web searching, I gave up trying to do this the efficient way and instead just drew two, unconnected triangles that happen to share two vertices.
		I defined four vertices, each with an <var>x</var> and <var>y</var> value of <code>-5</code> or <code>5</code>, then added two faces, one of which used all the vertices with at least one negative coordinate and one that used all vertices with at least one positive coordinate.
		I guess I didn&apos;t need to specify the edges manually?
		Anyway, a blue square now sat near the middle of the window.
		The square was a bit low to the bottom though.
		I&apos;m not sure why that is.
		Looking at the code that sets the camera&apos;s position, it should be pulled back along the <var>z</var> axis, but centred on the <var>x</var> and <var>y</var> axes.
		I could easily adjust the square&apos;s coordinates to compensate, but without understanding the reason the camera was off-centre, I was reluctant to compensate for it like that.
		The assignment never said the square had to be centred, so I left it.
	</p>
	<p>
		Next, it was time to rotate the scene.
		I wasn&apos;t sure how to do that, so I took a look at the code from last week.
		It was using the <code>autoRotate</code> method of an object returned from <code>THREE.OrbitControls</code>.
		It wasn&apos;t actually defining the rotation itself.
		Is that what I was supposed to do too?
		I undid all my changes to the template document to take a look at the original <code>&lt;script/&gt;</code> tags.
		Sure enough, a file with a name indicating that it was specifically for defining these controls was included.
		I was supposed to use the orbit controls.
		But also, i thought I realised what was going on with the university&apos;s JavaScript files.
		They were probably behind the school&apos;s login wall!
		I did a quick check, and saw that no, the university was actually just sending bizarre files instead of the JavaScript files.
		The one I looked at was mostly broken characters, but also mentioned OS X, something that looked like a Java package name Apple might produce given their domain name, and something about Google Chrome.
		None of that software is installed on my machine, so it wasn&apos;t some file reacting to my setup or something.
		It was just a broken or misnamed file.
	</p>
	<p>
		I copied over the orbiting code, figuring I&apos;d need to make changes before it&apos;d run, but tried it out anyway.
		It worked just fine.
		I&apos;d adjust it later anyway, but for now, I wanted to get a working sample in place.
		I definitely wanted to clean up the code before submission though, so all of this would be reworked a bit.
		The position of the square was really bothering me though.
		I looked through the code to see if I could find any code that looked like it offset the camera&apos;s view from its actual location somehow, and found that <var>VIEW_ANGLE</var> was set to <code>45</code>.
		That wasn&apos;t right.
		That should be <code>0</code> or <code>90</code>, I wasn&apos;t sure which, if we wanted to see the square head-on.
		That might be the cause of the offset.
		I set it to <code>90</code> and tried again.
		The result was much better.
		It was still a bit off, but it was within the range of what I&apos;d tolerate.
	</p>
	<p>
		Looking back at the instructions to see if I&apos;d missed anything besides the inclusion of comments, which I&apos;d add as I cleaned up the code, I saw that the assignment also wanted us to scale the object and move it elsewhere in space.
		How would the graders even know if the object had been scaled (verses defined at the shown size to begin with) or moved (as opposed to defined in the shown location to begin with)?
		These seemed like strange requirements.
		Additionally, the reading material this week told us how to scale in OpenGL, but we&apos;re instead working in WebGL.
		I tried looking up how to scale in WebGL, but it seems transformations in WebGL require shaders, which we haven&apos;t worked with.
		I mean, this is the first actual assignment.
		The textbook talked about shaders, but not how to produce them, and even if it had, it only talked about them in the context of OpenGL, not WebGL.
	</p>
	<p>
		I couldn&apos;t find any good tutorials on shaders, but from the scraps of information I was able to piece together from comparing what the tutorials I couldn&apos;t understand were doing, shaders seem to use very specific variable names for input.
		They don&apos;t even look like function arguments, but you basically use them as function arguments after declaring them.
		If they have the right name, WebGL will set those variables as if they were arguments being passed in.
		It&apos;s a confusing system, likely related to WebGL&apos;s (and OpenGL&apos;s) unintuitive choice to operate on global variables outside the shaders too, instead of using arguments and return values like a clean library does.
		From the code samples I could find, it seemed that <code>getWebGLContext()</code> needed to be called on the canvas to return some other object with properties we could use to initialise the shader with, but what canvas?
		I couldn&apos;t find any canvas objects in the code we were working with.
		The closes thing I could find was the scene object, but passing that into <code>getWebGLContext()</code> (even without doing anything with the returned object) prevented rendering, as did passing in anything I could think might work, including passing nothing.
		It was like the call to <code>getWebGLContext()</code> itself was breaking the rendering, and seemed to have nothing to do with the argument.
		I did notice that some of the setup code for the rotation was actually included in the boilerplate part of the template though, so I was able to delete my copy of it from the section we were supposed to edit.
	</p>
	<p>
		Eventually, I had to give up.
		We haven&apos;t covered how to use shaders yet, or if we did, I didn&apos;t understand it.
		And why would we even be jumping right into shaders in the first assignment, the one in which we were just figuring out how to even get geometry to render at all?
		It made no sense.
		Getting a shape of our choice in a colour of our choice and making it spin seemed like a good first assignment on its own.
		It seems like shaders should be given their own assignment, at the very least, not to mention that the assignment this week didn&apos;t even mention shaders.
		For that matter, it didn&apos;t even tell us to scale or translate the square, it only said that we&apos;de be graded on whether or not we&apos;d demonstrated how to scale and translate objects.
		There were no actual instructions telling us in where or why to move the square or why  or to what size to scale the square.
		Things just weren&apos;t adding up.
		Due to seeing this assignment&apos;s grading rubric early, as it was mistakenly used as the grading rubric for last week&apos;s work, I knew I&apos;d be penalised for not showing a translation or scaling, but I just couldn&apos;t figure out how to pull it off.
		I&apos;ll just have to accept the lower grade and try to do better next week.
	</p>
	<p>
		While cleaning up the code and commenting, I set the triangles to only render from one side.
		That allowed me to see that my triangles were actually facing opposite directions, so I reordered my vertices, then built new triangles using those vertices in a more-consistent manner.
		That got them to face the same way, after which I made them render on both sides again.
		I ended up removing the camera angle adjustment I&apos;d added at first too.
		It didn&apos;t seem to be necessary, or even useful, by the time I got to cleaning up that part of the code.
		I think the off-centre issue was because the console wasn&apos;t letting me scroll all the way to the bottom or something.
		When the console is completely minimised, the square seems centred just fine.
	</p>
</section>
<section id="Unit3">
	<h2>Unit 3</h2>
	<h3>Describe what you did.</h3>
	<p>
		For the week, I read the material, graded assignments from last week, and participated in the discussion activity of the week.
		I also built a bouncing sphere animation for the main assignment of the week.
		I ended up overcomplicating the assignment, but my animation turned out better for it.
	</p>
	<h3>Describe your reactions to what you did.</h3>
	<p>
		I suppose my main reaction to what I&apos;ve done this week was frustration.
		I stayed up late trying to fix my janky animation, only to find out that the one part that was causing my trouble, the <var>z</var> dimension, was something we didn&apos;t even need to include in our submissions.
		The frustrating part was that I&apos;d done that to myself.
		It was me that failed to read the directions correctly.
	</p>
	<h3>Describe any feedback you received or any specific interactions you had.</h3>
	<p>
		Discussion assignments do absolutely zero for me.
		Any &quot;interactions&quot; there tend to consist of either us all repeating the same things, because we&apos;re all answering the same questions after reading the same material, or people going off-topic.
	</p>
	<p>
		With that in mind, the only real interaction I had in regards to this course was from our professor about my <a href="https://y.st./en/coursework/CS4406/#Unit1">Unit 1 learning journal</a> submission.
		I was told not to tell what the textbook told me, but at the same time, to tell what I learned.
		As what I learned came from the textbook, these requests are in direct opposition to one another.
		I&apos;m not sure what I&apos;m supposed to do.
		However, I was also told to answer a series of questions, questions I&apos;d already answered, just in the context of a full write-up.
		I can only assume that my best option is to now specifically answer each question individually in its own section to be sure each one gets recognised as having been answered.
	</p>
	<h3>Describe your feelings and attitudes.</h3>
	<p>
		I suppose the one thing I didn&apos;t cover before were my feelings and attitudes, as they aren&apos;t really relevant to what I was doing, not to mention that they&apos;re pretty much always the same.
		My main feeling is one of constant lethargy, and my attitude is that I just want to get the work over with.
		I used to thoroughly enjoy my studies here at this school, but that all ended a little over a year and a half ago.
		This school has drained the joy of learning right out of me.
		Since 2017-11-01, I&apos;ve just wanted to get my schooling done so it can be over with.
		It has nothing to do with this course, or any specific course, and isn&apos;t anything that you&apos;re doing wrong.
		Rather, the way the school is run.
		It&apos;s not a healthy environment, and I&apos;ll be happy when my time here is finally over.
	</p>
	<p>
		So what is my attitude?
		My attitude is that I&apos;ve only got two more years here, and then I&apos;ll be free.
	</p>
	<h3>Describe what you learned.</h3>
	<p>
		You want me to talk about what I learned, but not talk about what the textbook said.
		Honestly, I don&apos;t know what to say.
		What I learned came from the textbook.
	</p>
	<p>
		I suppose in short, I learned how to properly move objects about in space using <code>three.js</code>.
		That was something I couldn&apos;t figure out last week, and couldn&apos;t find information on how to do on the Web.
		That would be the main thing.
		I also learned how to better deal with collision detection, at least for some cases.
		My sphere was acting all sorts of wonky when it hit edges of the viewing area, due to slightly clipping into them, then repeatedly detecting a collision and repeatedly trying to switch directions to get back out.
		The sphere misbehaved because it would flip directions to get out of the wall, fail to get all the way out, then flip again to get out but actually be heading further in now.
		An easy fix was to shove the sphere back out right away, so when it turned around, it&apos;d already be out of the wall before it moved.
	</p>
	<h3>What surprised me or caused me to wonder?</h3>
	<p>
		I&apos;m constantly wondering how to get my work done in this course.
		When I ask a search engine for even the most basic advice on how to perform some simple action in <code>three.js</code>, it gives me bupkis.
		I can&apos;t remember all the $a[API] calls from the textbook, and need to be able to see basic method signatures while I&apos;m working.
		Even in languages and $a[API]s I work with frequently, I have to constantly check the the Internet for function names and argument lists.
		And with <code>three.js</code>, I don&apos;t even have the luxury of being familiar with the language or the $a[API]!
		I&apos;d never heard of <code>three.js</code> before this course, and I almost never touch JavaScript code.
	</p>
	<h3>What happened that felt particularly challenging? Why was it challenging to me?</h3>
	<p>
		What was challenging this week?
		Well that&apos;s easy: the programming assignment.
		Why was it challenging?
		Because I misread the directions, over-complicated things, and implemented a feature it turned out we were never intended to have to deal with: bouncing the object in the <var>z</var> direction in a perspective-view-defined box while simultaneously bouncing the object in the <var>x</var> and <var>y</var> directions.
		The slanted walls of the view really bugged up my results until I added some code that specifically dealt with the object clipping into the walls, which was something it never did when I had it only bouncing in two dimensions.
		Having three dimensions along with slanted walls caused the object to enter the walls when moving toward them, triggering repeated collision detection and causing the object to bounce back and forth <strong>*within*</strong> the wall.
	</p>
	<p>
		Debugging the wall position code was also a challenge, as I&apos;d worked out the perfect equation to represent the wall, and it was somehow not even close to perfectly representing the wall.
		It turns out I accidentally left out a negative sign in my equation.
		An easy fix, but not an easy bug to track down.
	</p>
	<h3>What skills and knowledge do I recognize that I am gaining?</h3>
	<p>
		Before this course, I couldn&apos;t do anything in {$a['3D']}, and now I can.
		So that&apos;s something.
		I could visualise in {$a['3D']} and I could understand {$a['3D']} coordinates.
		I often have to when I work on the plug-ins I write for Minetest, a game I play when I have time.
		But that was the extent of my skills in virtual {$a['3D']} space.
	</p>
	<p>
		At this point, I can add lights to specific spots, or even add ambient lights.
		I can also sort of define objects using <code>three.js</code>, though not any complex ones.
		I can also move objects around and perform very basic collision detection.
		I feel like what I wrote this week was a desktop screen saver, but hey, I couldn&apos;t do that before.
	</p>
	<h3>What am I realizing about myself as a learner?</h3>
	<p>
		What I realise about myself as a learner is that I learn a lot more when I write extensively about what I&apos;m learning.
		When I&apos;m struggling to grasp the material in a course, such as this one, writing about the problem often helps me retain what I&apos;ve learned and sometimes work through the parts I don&apos;t quite understand.
		When I don&apos;t write, I don&apos;t learn, so when I don&apos;t write much, I don&apos;t learn much.
	</p>
	<h3>In what ways am I able to apply the ideas and concepts gained to my own experience?</h3>
	<p>
		Honestly?
		I&apos;m not sure any of this applies to what I do outside of school.
		This sort of question is one f those traps, where you can either lie and claim the material is really useful and try to come up with some bogus use for it to explain, or you can be honest and admit that you don&apos;t see how this applies to you.
		This sort of question is an underhanded one to include in an assignment.
	</p>
	<p>
		Anything that&apos;s written with accessibility in mind doesn&apos;t use JavaScript, which means the $a[API] we&apos;re learning is something I won&apos;t use just because good webpages don&apos;t depend on JavaScript.
		<code>three.js</code>&apos; $a[API] seems to be so drastically different than what we&apos;re sort of learning OpenGL&apos;s $a[API] is like, too.
		Every time I find an answer as to how to do something in <code>three.js</code>, it&apos;s way different than what I read you have to do in OpenGL.
		If we move on to learn OpenGL&apos;s $a[API] at some point, that&apos;s something I&apos;ll actually be able to apply.
	</p>
	<p>
		For now, the main thing I&apos;m getting from this course is terminology.
		There are terms I see used that make no sense in the programs they&apos;re used in.
		The words don&apos;t match what actually happens.
		For example, something labelled &quot;shaders&quot;, that doesn&apos;t shade anything, but instead makes objects move around a little in space.
		What&apos;s that about?
		However, this course is explaining terms such as that.
		No doubt, in my example, the object movement is implemented using OpenGL shaders.
		Shaders in that context have nothing to do with shading, and are instead just small programs executed on the $a[GPU] that can influence a rendering.
		Understanding that makes the interfaces of programs I use elsewhere make much more sense.
	</p>
	<h3>Ignore the following.</h3>
	<p>
		I wrote up a full report on my activities for the week before I saw your feedback for my <a href="https://y.st./en/coursework/CS4406/#Unit1">Unit 1 learning journal</a> submission saying not to do that.
		I really didn&apos;t want to just delete all my work.
		Submitting it makes it eligible to be archived though, so I&apos;m including it here as an add-on.
		You don&apos;t need to read or grade anything below here.
	</p>
	<p>
		The reading assignment for the week was <a href="https://www.cs.csustan.edu/~rsc/NSF/Notes.pdf">Notes.pdf</a>, chapters four and five.
	</p>
	<p>
		The section on the Cartesian coordinate system was confusing at first.
		I couldn&apos;t figure out what it was trying to get across.
		Once I realised the points it was getting at though, I realised it was all stuff I already knew.
		I&apos;ve used the {$a['2D']} Cartesian space a lot in high school, and the {$a['3D']} Cartesian space in a game I develop plugins for.
		Neither of these spaces in unfamiliar territory for me, though I&apos;m always found it strange that <code>y</code> is the vertical one instead of <var>z</var>.
		After making it partway through this course though, I see that that&apos;s either common practice or it&apos;s something that comes from graphics libraries.
		If the latter, the developers probably used <var>y</var> as the vertical axis to make the code easier to understand, which I appreciate.
		Eventually, I&apos;d love to join the development team myself, and having easier to understand code will be nice.
		I&apos;ve got to learn the language first though.
		The source code is fully available for me to read and tinker with, but it&apos;s written in C++, a language I&apos;ve never actually worked with before.
	</p>
	<p>
		The term &quot;octant&quot; was new to me.
		I would have assumed the eight sections to be called &quot;sectors&quot; or something, but it makes more sense that if the {$a['2D']} term is four-specific, the {$a['3D']} equivalent would be eight-specific.
	</p>
	<p>
		Dot products are weird.
		I had to go back and read what the computation was supposed to yield after reading the equation itself before I could understand the equation, as for some reason, I thought they were supposed to produce a point in space in which the two vectors cross.
		Instead, you multiply the components of each vector with the corresponding components of the other vector (<var>x</var> from one with <var>x</var> from the other, et cetera), the add the resulting values together.
		What could that result possibly tell us though that could be useful to us?
		The textbook next talked about how the dot product is zero when the vectors intersect at a 90° angle, positive if they form an acute angle, and negative if they form an obtuse angle.
		That seems useful at first, but before even talking about that, the textbook first tells us that for parallel vectors, the dot product is either positive or negative depending on whether the vectors are pointing in the same or opposite directions.
		That means we can&apos;t use the dot product to determine angle properties, as when there is no angle formed, because the sign of the dot product doesn&apos;t mean the same thing all the time.
		My understanding is that the dot product will never be zero for parallel vectors, so we can still properly detect right angles, but otherwise, I&apos;m not sure how a dot product helps us.
		At least the dot product, combined with the lengths of the vectors, can be used to compute the angle formed.
		angle measures are often useful to know.
	</p>
	<p>
		It was stated that reflection- and ricochet-calculation require knowing the normal vector of the plane the light/object hit, but I don&apos;t really get why that is.
		It seems that another valid way to calculate the new trajectory would be to take the line segment running through the plane that represents where a plane would intersect that plane while also containing the full path of the light/object.
		From there, you&apos;d take 180° and subtract the initial impact angle.
		It&apos;s as easy to picture why this works as it is to picture why reflecting over the normal vector works, though it might be easier to calculate using the normal vector method.
		I&apos;m not really sure.
		Either way though, knowing the normal vector doesn&apos;t see to be strictly necessary as the book seems to imply it is.
	</p>
	<p>
		Previously, the textbook talked about how graphics libraries represent transformations using matrices.
		I was curious as to how rotations could possibly be handled that way.
		It turns out it&apos;s not overly complicated.
		The trick is to insert sine and cosine values into the matrix you multiply by.
		I can&apos;t say I understand why sine and cosine behave the way they do, but their wave-like form comes in handy a lot of times, and this would be one of those times.
		I doubt I&apos;ll be able to remember which cells need which functions and which ones need to be made negative, but the graphics library handles that mostly on its own, if I&apos;m not mistaken.
	</p>
	<p>
		The book shows a diagram with a &quot;point G&quot;, which lies in a hole crated in a convex polygon by the overlapping edges that contain it.
		The book says that this point is intuitively inside the polygon, but is outside because of the ray-based definition of being &quot;inside&quot; that the book gives.
		Personally, I find it intuitive to think the point is outside the polygon.
		I mean, try making such a polygon out of some real material, such as wood.
		Or even just try shading in the polygon using an image editor.
		That spot is a hole.
		It doesn&apos;t get shaded.
		There&apos;s no wood there, if you build it out of wood.
		The polygon <strong>*surrounds*</strong> that point, but it doesn&apos;t <strong>*include*</strong> that point.
		I guess that&apos;s the difference though in how I consider a point to be &quot;in&quot; a polygon.
		I think of that as meaning that the point is a part of the polygon; the polygon being <strong>*around*</strong> the point isn&apos;t enough.
		I think my vision of this is compatible with the book&apos;s ray-centric definition, too.
	</p>
	<p>
		I think why many people might find this definition unintuitive is because this sort of polygon violates their internal model of what a polygon is.
		Quite frankly, having a polygon&apos;s edges cross over one another is ... weird, to say the least.
		And because of that, I think people have difficulty visualising it.
		As a result, they instead visualise a different polygon than the one that&apos;s actually presented, with the cross-over edges removed.
		Essentially, they fill in the hole in the middle of the polygon in their mind.
		Because of that, there is no hole to them, so any point occupying the spot the hole would be is seen as not being in a hole at all, but actually within the bounds of the polygon.
	</p>
	<p>
		The section on collision detection was enlightening.
		Bounding boxes aren&apos;t a new concept to me; they&apos;re very similar to actual collision boxes.
		What I found interesting though was the idea of using these bounding boxes not to detect collision, but instead <strong>*rule out*</strong> collision before performing the actual collision detection.
		That way, the computationally-expensive tests usually don&apos;t need to be performed.
		I&apos;m also surprised to see collision detection presented in a book about graphics though.
		It doesn&apos;t seem to be a graphics-related concept, mostly.
		I guess it makes sense though.
		If objects collide, you need to account for that when deciding where to draw them.
	</p>
	<p>
		The polar coordinate system is something I&apos;ve learned about, but something I usually write off.
		It seems like such a bizarre system.
		It&apos;s useful in a few edge cases though.
		I forget exactly what those edge cases are, but I think I remember they come up when dealing with trigonometric functions such as sine, cosine, and tangent.
		Spherical coordinates seem like a natural extension of polar coordinates in {$a['3D']} space, so again, they don&apos;t seem like the best option in most cased, but might have some use for edge cases.
		Cylindrical coordinates are even stranger to me, as one of the dimensions is measured normally, while the  other two are measured according to a polar coordinate system.
		I guess the book&apos;s example of using them for objects that can spin but must always remain upright makes sense though.
		You still need to translate these coordinates into proper Cartesian coordinates at some point, but it&apos;s often the case that abstracting away the real system in place (for example, Cartesian coordinates) in favour of some other system (cylindrical coordinates) can make life easier for the programmer.
	</p>
	<p>
		When I saw the discussion assignment this week, I rejoiced.
		As I demonstrated last week, I&apos;m completely terrible when it comes to building {$a['3D']} models and such, because I have no experience with them yet.
		But alpha channels?
		Those relate to {$a['2D']} graphics.
		I have pretty much no artistic talent even in {$a['2D']}, but I still have years of practice with {$a['2D']} graphics, so I&apos;m well aware of a lot of the mechanics, such as alpha channels.
		One of the big struggles for me is my tight schedule.
		My first goal each week is to post at least once in the discussion forum for one of my courses each day.
		Due to how the discussion boards at this school are set up, you can only respond to other students after posting your own initial post, meaning that on day zero, I&apos;ve got to do my best to cobble together an initial post from whatever reading material I manage to get through by the end of the day, and the next day, if someone else hasn&apos;t posted in that same course&apos;s discussion board, I&apos;ve got to repeat the process for my other course to submit my initial discussion post there.
		It&apos;s a tight schedule, and it stresses me out.
		But this week, I didn&apos;t have to madly scramble on the first day this week.
		I could lean on my prior knowledge, and use that to find exactly the sources I needed to back up my thoughts without having to learn the concept all in one day.
		I still read much of the material before posting because there was time to do that, but I didn&apos;t have to struggle through it as I have in past units.
		It was covering things I already understood very well.
	</p>
	<p>
		One of the quirks of the system seems to be that once you specify a colour to draw in, that colour is permanent and applied to all your other objects you draw later.
		At least, until you manually set a new colour.
		You don&apos;t set colours per-object, but instead set the colour for all future objects, then change it when needed.
		This is no doubt because graphics libraries use global variables instead of parameters.
		Setting the colour probably sets some global variable (or variables), and that value stays set until you set it to some other value.
		I&apos;ve got to wonder if this even applies to WebGL though, which doesn&apos;t seem to use the same setup as the graphics libraries discussed in this book.
	</p>
	<p>
		It&apos;s important to note that you have to define the appearance node before the geometry node.
		The appearance node defines some things about how the object will be rendered, such as its colour.
	</p>
	<p>
		The section on considering the $a[RGB] colour space to be a cube was interesting.
		Especially when trying to build a good palette, I&apos;ve often thought about the colour space as a cube.
		However, I&apos;d never heard of anyone else doing that.
		It seems I&apos;m not the only one that thinks that way though.
		The difference between my cube an the book&apos;s cube though is that I think in discrete values.
		My cube goes from <code>0</code> to <code>255</code>, not from <code>0.0</code> to <code>1.0</code>.
		It&apos;s likely that we&apos;re going to be working with colour fairly regularly, and I&apos;m going to need to convert back and forth between the colour representation I work best with and the colour representation the graphics library uses.
		<del>The book makes the claim that you can see the full range of colours on the surface of the cube though, which as someone that has done a lot of planning using this cube, I can say is patently false.</del>
		You only see a small fraction of the colours on the surface.
		The only colours you see on the surface are ones in which one of the colour channels is set to full intensity or zero intensity.
		As an extreme example, try to find grey on the surface.
		You can&apos;t do it, as grey occupies the centre line diagonally through the core of the cube.
		<ins>Oops, the book corrects itself a bit later, and admits that the interior of the cube also represents various colours.
		An it even mentions the diagonal line of greys I just talked about.</ins>
	</p>
	<p>
		I&apos;ve also thought about colours as an octahedron.
		In this representation, each of the eight basic colours has a face, and that face is adjacent to the three faces that share two colour channel values with it.
		It&apos;s not a useful representation though, as it only takes into account those eight colours.
		There&apos;s no middle ground between them.
		I&apos;ve often thought of colours in terms of shapes though.
	</p>
	<p>
		The concept of luminance is interesting.
		When the book first brought it up, I wrote it off, thinking that it wouldn&apos;t matter much.
		We can&apos;t actually program in the luminance we want, at least not directly.
		The colour channels are what we actually work with.
		So they&apos;re what matters, right?
		The book made an excellent point about colour blind people though.
		Making images with different-enough luminance levels will help them interpret the image.
		The formula for finding the luminance of a colour was also surprising.
		<code>0.30*red + 0.59 * green + 0.11*blue</code> ...
		The three colour channels don&apos;t contribute equally to the luminance like I thought they did.
		I experimented in the $a[GIMP] a bit to see how it handles luminance-based greyscale conversion, and sure enough, perfect red, perfect green, and perfect blue don&apos;t get converted to the same shade of grey.
		Green is by far the lightest, while blue is just a bit darker than red.
		Weird.
	</p>
	<p>
		The book claims the Hue-Saturation-Value colour-specification scheme to be more intuitive than $a[RGB].
		I&apos;m not seeing it though.
		I agree that it can be difficult to find certain colours when using the $a[RGB] scheme.
		Brown, for instance, is a colour I have difficulty specifying in $a[RGB] format.
		However, the Hue-Saturation-Value format requires you to use a numeric representation of a hue.
		What does that even mean?
		Line, I understand what it actually means, but if I&apos;m looking for a greenish colour, what hue number do I use?
		Green doesn&apos;t translate to a number in my mind.
		However, specifying that I want my colour to have a high green channel intensity and a low red  and blue channel intensity is a very intuitive way to find green.
		And other colours are often (though not always, such as is the case with brown for me) very easy as well.
		I light blue for lining clouds with, for example, would have a high blue, a mostly-high green, and a high red that&apos;s not quite as high as the green channel.
		That would give you a light blue colour with just a tad bit of cyan.
		Perfect.
		How do I even go about <strong>*starting*</strong> to find that colour in Hue-Saturation-Value space?
		I can finish the job with the right saturation (low, but not too low) and value (high, but probably not too high), but those numbers don&apos;t get me anywhere without the hue number.
	</p>
	<p>
		The Hue-Lightness-Saturation model is just as unintuitive to me as the Hue-Saturation-Value model.
	</p>
	<p>
		The $a[CMYK] model is familiar to me, and seems to me to be about as intuitive as the $a[RGB] model.
		It&apos;s a subtractive model instead of an additive one, but it really does represent the same, cubic colour space that the $a[RGB] model uses.
		You just measure from different places.
		For example, instead of measuring how much red there is, you measure instead how much cyan there is.
		Rend and cyan are opposites, so these two corresponding measures give you exactly-opposite values every time.
	</p>
	<p>
		When the textbook mentioned that some systems don&apos;t allocate the same number of bits for each colour channel, it reminded me of the old eight-bit colour system.
		Three bits were allocated to each red and green, but only two bits were allocated to blue.
		Humans aren&apos;t as good at distinguishing levels of blue as we are levels of red and green, so it was thought that it was worth losing that extra bit of blue depth to get the colour into an eight-bit format.
	</p>
	<p>
		Transparency in {$a['3D']} images is clearly very difficult.
		Order of rendering matters, but in {$a['3D']} space, objects can intersect.
		Their intersection marks the point at which which object needs to be rendered first for proper results switches.
		You can&apos;t draw in both orders, so one side of the image will come out wrong.
		However, I couldn&apos;t help but wonder if we could learn something from clipping planes here.
		What if the plane of one object was used to clip the other object&apos;s plane, and instead of throwing one side out like we do with clipping planes, we saved both sides as separate planes?
		We could then draw the side of the split plane that needs to go in back first, they draw the plane that was used to split the other plane, and finally draw the front part of the split plane.
		Both planes would then be drawn in the correct order in all parts.
		It gets even more complicated as you add more-complex meshes and a higher number of translucent objects, but I think the idea is sound.
		The main issue, I think, would be that it&apos;d be computationally expensive.
		It could be worth it in some cases though.
		After writing about my solution, the next thing I read in teh textbook was pretty much the same thing, but with even more splitting.
		Everything that intersects gets split.
		It&apos;s probably easier to calculate that though, as you don&apos;t need to try to figure out which cuts are necessary ans which aren&apos;t.
	</p>
	<p>
		The assignment instructions this week told us how to translate objects to other locations.
		That would have been helpful information to have for last week&apos;s assignment.
		I couldn&apos;t figure out how to do it.
	</p>
	<p>
		Anyway, we were to take a cube, a sphere, or a torus knot and bounce it around in the viewport.
		At first, I tried to use a sphere.
		However, we were supposed to get the object to change colours each time in hit a wall, and I couldn&apos;t even set the initial colour.
		It just had this odd rainbow-like gradient to it, and no matter what colour I tried to set, the same colours were present on the sphere.
		So I made a cube.
		But the cube looked like a square, as you see it dead-on.
		I could fix that by rotating it, but we&apos;re not supposed to do that for this assignment.
		So I went back and tried to debug the sphere some more.
		What I discovered is that the <code>THREE.MeshNormalMaterial()</code> doesn&apos;t seem to want to change colours for me.
		The <code>THREE.MeshBasicMaterial()</code> works just fine though.
		However, it doesn&apos;t have any depth to it, so the object just looks like a circle, or rather, a polygon with many sides that approximates a circle.
		<code>THREE.MeshLambertMaterial()</code> gave me something workable though; something that responded to my colour-setting code, but also had a concept of light and shadow.
	</p>
	<p>
		Getting the sphere to bounce off the walls wasn&apos;t too hard.
		I used global variables to set a &quot;direction&quot; the sphere would travel in each dimension, but the &quot;direction&quot; was actually a speed.
		When the position of the sphere got too far, I set the speed to its own inverse, which made it travel in the opposite direction, but only along that particular axis, providing a ricochet effect as the sphere continued in the previous direction along the other two axes.
		I also set a new colour at that point.
		I thought about setting a random colour each time, but decided to instead use six of the eight basic colours, and have the colour switch to a specific one based on what wall the sphere bounced off of, giving each of the six walls its own sphere colour.
		My problem was that I couldn&apos;t figure out how to properly change the maximum and minimum <code>x</code> and <code>y</code> bounds based on the <var>z</var> position.
		The viewing space isn&apos;t a rectangular prism, so if I didn&apos;t account for the <code>z</code> value in the <var>x</var> and <var>y</var> bounds, the sphere would either bounce off of nothing when far away or clip into the wall when close to the camera.
		It&apos;d help if I understood what the angle of the view was.
	</p>
	<p>
		What I ended up doing was setting the sphere to the far back of where I&apos;d just sort of decided to place the back (invisible) wall, then moving the sphere around until I&apos;d gotten it into a corner, and recorded the position.
		Then I did the same with the front wall.
		Using those positions, I set up a linear equation that would return those two specific values, which then returned sensible values for the cases in between.
		I think I was supposed to bounce the sphere off the clipping planes themselves, if I understood the assignment correctly, but I have no idea how to even <strong>*find*</strong> the clipping planes, let alone interact with them.
		I think I was supposed to put together real collision detection, but instead, I only approximated it.
		After setting all this up, I found the <var>VIEW_ANGLE</var> variable.
		I think that&apos;s probably the angle I was looking for before, but somehow missed.
		I&apos;m really terrible at this.
	</p>
	<p>
		I never could find a good initial placement for the sphere that showed off the bouncing well.
		It always tended to bounce around in a very obvious cycle.
		I tried several values, but gave up and set the starting position to be random every time.
		Once I&apos;d done that though, it occurred to me what the problem was: the viewport is square!
		A square box with 45°-angled bounces (due to the velocity in all three dimensions - but most importantly, the <var>x</var> and <var>y</var> dimensions - being identical) isn&apos;t going to give good results.
		I was about to try setting some different velocities, but decided to make those random as well, because why not?
		My first attempt made the sphere speed around so quickly the graphics renderer couldn&apos;t keep up.
		It was literally leaving after images in its path.
		I didn&apos;t like the look of that, so I divided the random value by four.
		I have no idea why, but I actually multiplied them by <code>0.25</code> instead of actual division at first.
		It didn&apos;t even occur to me that I could use division until I wrote in my learning journal that I&apos;d divided the values.
		I rewrote it using actual division, as it provided better clarity in the code.
		I ended up dividing by eight instead of four later, as I seemed to be getting higher speeds and needed to dampen them further.
		I think my machine had cleared out the WebGL stuff that was bogging it down (WebGL slows down my computer and makes it start overheating, but I set down the assignment for a while and closed the browser), so it was performing faster when I started working with WebGL again.
	</p>
	<p>
		Also of note, when I reread the assignment to make sure I covered everything, I found that it said to modify the <var>x</var> and <var>y</var> values.
		It said nothing about moving the object in the <var>z</var> direction.
		That seems contradictory to its insistence a bit prior to that saying that we shouldn&apos;t animate in {$a['2D']}, but in {$a['3D']}.
		This was actually supposed to be a {$a['2D']} animation though.
		I&apos;d overcomplicated it.
		There were a few strange bugs caused by <var>z</var>-direction movement I&apos;d had to figure out, not to mention that I&apos;d had to get the angled bounding walls to function correctly with a combination of guessing, checking, and a linear equation.
		Whatever, though.
		My actual animation came out slightly better for being able to move in all three dimensions, and the frustration of trying to figure out how to do that properly is something I won&apos;t have to struggle with as much should we do something similar in the future.
	</p>
	<p>
		One of the questions on the quiz confused me for a bit.
		It presented a rectangle and gave the coordinates of the opposing two vertices.
		Obviously, by doing that, it gave us the coordinates of every vertex, as you just carry over the <var>x</var> value from the known vertex positioned the same horizontally but not vertically and the <var>y</var> value from the vertex positioned the same vertically but not horizontally.
		However, the <var>y</var> values didn&apos;t make much sense.
		The one closer to the top of the page had a higher value.
		It took me a few seconds to realise I hadn&apos;t messed something up, and that the <var>y</var> values were just reversed.
		The course material did mention that some systems count from the bottom instead of the top.
	</p>
	<p>
		When grading this week, the first student&apos;s work I looked at wouldn&apos;t render.
		I&apos;m not sure if that was a problem on my end or theirs.
		The second student went above and beyond.
		They implemented full keyboard controls for their square&apos;s motion.
		I was thoroughly impressed.
		The third student though said only to see their attached file, but didn&apos;t actually attach a file.
		That was a shame.
		I had to give them a zero, as they hadn&apos;t actually submitted any code, but it sounds like they did actually write it and intend to upload it.
	</p>
</section>
<section id="Unit4">
	<h2>Unit 4</h2>
	<h3>Describe what you did.</h3>
	<p>
		I read chapters eight and nine of <a href="https://www.cs.csustan.edu/~rsc/NSF/Notes.pdf">Notes.pdf</a>, graded papers, participated in the discussion assignment, wrote up this learning journal entry, and wrote up code to make a moving scene with five spheres.
		I also did research on my own, which helped much more with the assignment than the material the book covered did.
	</p>
	<h3>Describe your reactions to what you did.</h3>
	<p>
		The assignment this week literally gave me a headache.
		My reactions for the week are pretty much those of pain, frustration, and exhaustion.
	</p>
	<h3>Describe any feedback you received or any specific interactions you had.</h3>
	<p>
		From the professor, I got the feedback that I should limit my learning journal entries to around 500 words.
		I do most of my learning by writing, not by reading alone, so the less I write, the less I learn
		Still, I&apos;ll do my best to follow your request.
		Keep in mind that a glitch in the school&apos;s word counter causes page markup such as paragraph and header tags, which are vital in making my posts readable, to be counted as words in the word count displayed, while I won&apos;t count those, and I also won&apos;t be counting the header questions, because it&apos;s already difficult to write so little and I&apos;m not the one that wrote those headings.
		Even with that though, I&apos;m not sure how to answer all the questions while keeping below that limit, and will have to go above a bit.
	</p>
	<h3>Describe your feelings and attitudes.</h3>
	<p>
		I also feel like the textbook is teaching us one thing, then the assignments are having up put something else entirely into practice.
		The textbook seems to be about actual graphics libraries, while the assignments revolve around this obnoxious <code>three.js</code>, which has a radically different $a[API] than the graphics libraries.
		My guess is that working with <code>thee.js</code> is supposed to be &quot;easier&quot;, but it&apos;s not easier when that&apos;s not the $a[API] we&apos;re reading about.
		So we&apos;re not putting what we read into practice, then we have to put what we don&apos;t know into practice instead.
	</p>
	<p>
		To top it off, <code>three.js</code> is so resource-intensive that it locks up my computer for about a minute at a time every once in a while.
		I can&apos;t move the cursor and my clock in the corner (which includes a seconds ticker) completely stops ticking.
		I keep thinking that my computer froze, but the thing goes back to running after a while.
	</p>
	<p>
		I also feel like the assignments are a bit unclear as to what they want from us.
		The main part of the assignments is very clear.
		However, we&apos;re also told at the end that we&apos;ll be graded on whether we demonstrated the ability to rotate, scale, and translate objects, even though no part of the assignments told us to do any of that.
		So do we add those wherever we see fit as random quirk specific to our submissions?
	</p>
	<h3>Describe what you learned.</h3>
	<p>
		By ignoring the textbook when it comes to the assignments, I&apos;m finding it easier to learn the <code>three.js</code> $a[API].
		The <code>three.js</code> $a[API] does seem to be more intuitive than what the textbook tells us graphics library $a[API]s are like.
		There&apos;s none of this defining global variables, having the functions that define geometries reading them, then setting them to other values before defining other geometries.
		<code>three.js</code> instead uses object properties and methods, which apply only to specific objects, which is something I really thing the graphics libraries should do as well.
	</p>
	<h3>What surprised me or caused me to wonder?</h3>
	<p>
		I wonder why the <code>three.js</code> manual is so disorganised.
		I&apos;ll spare the details because you want this kept short, but there are multiple menu sections with the exact same labels, so when you find one, you think the items in the other are missing from the manual.
		And then, there&apos;s the stuff that&apos;s missing from the navigation menu altogether.
		What a disorganised mess.
	</p>
	<h3>What happened that felt particularly challenging? Why was it challenging to me?</h3>
	<p>
		The most challenging thing for the week was not having proper documentation to work with, as I mentioned a bit ago.
	</p>
	<p>
		Aside from that though, my choice to use cubes gave me more trouble than anything else.
		No matter what I tried, I couldn&apos;t get cube 3 to reflect the local light source.
	</p>
	<p>
		Finally, I found some random page by someone <a href="https://blog.disignstudio.com/materials-and-light-basics-in-three-js/">demonstrating the different materials and lighting effects</a> with a variety of shapes, including cubes.
		In the scenes with specular highlighting, the shapes with flat faces had no specular highlighting.
		The shapes that pretended to have curves, on the other hand, did, and within the same scenes, too.
	</p>
	<p>
		Another difficulty was that the Web browser was blocking images from being loaded.
		JavaScript drives me absolutely bonkers.
	</p>
	<h3>What skills and knowledge do I recognize that I am gaining?</h3>
	<p>
		I can now properly use materials to cover the sides of an object in <code>three.js</code>.
		<code>three.js</code> itself is of zero use to me, but knowledge on how the different materials themselves work could be useful in future projects I work on.
	</p>
	<h3>What am I realizing about myself as a learner?</h3>
	<p>
		I realise the same thing I&apos;ve realised for a long time: the less I write, the less I learn.
		I&apos;ve also learned that next week, to make my learning journal entry shorter, I need to limit my word count for each answer to about 50 <strong>*beforehand*</strong>, so nothing needs to be deleted.
		This week is a lost cause though, and I&apos;ve deleted as much as I feel I could from it already.
	</p>
	<h3>In what ways am I able to apply the ideas and concepts gained to my own experience?</h3>
	<p>
		I&apos;ll need to do some experimenting in Blender to be sure, but I think I can use what I&apos;m learning about materials to develop Minetest-compatible models.
	</p>
</section>
<section id="Unit5">
	<h2>Unit 5</h2>
	<h3>Describe what you did.</h3>
	<p>
		I read chapters ten and eleven of <a href="https://www.cs.csustan.edu/~rsc/NSF/Notes.pdf">Notes.pdf</a>, graded assignments from last week, participated in the discussion assignment, and built a model of a methane molecule.
	</p>
	<h3>Describe your reactions to what you did.</h3>
	<p>
		On two separate days, I nearly gave myself another headache trying to figure out the programming assignment.
		Thankfully, unlike last week, I was able to figure out the parts I was stuck on before reaching a full-blown headache.
	</p>
	<h3>Describe any feedback you received or any specific interactions you had.</h3>
	<p>
		I got the feedback on my <a href="https://y.st./en/coursework/CS4406/#Unit3">Unit 3 learning journal</a> submission again telling me to limit my writing to 500 words.
		I&apos;d like you to know that I read that initial request, and am doing my best to fulfil that request, but that it takes me two weeks to react.
		On the first week, you grade, and on the next week, I&apos;m able to respond to that feedback in the next submission.
		As a reminder though, I&apos;m not including the headings and markup in that word count as it&apos;s already so limited, while the automated word count does include them.
	</p>
	<h3>Describe your feelings and attitudes.</h3>
	<p>
		My feelings and attitudes are those of frustration.
		This is so much harder than it needs to be.
		With better instructions, this is the kind of thing I&apos;d find outright easy.
	</p>
	<h3>Describe what you learned.</h3>
	<p>
		In order to keep my journal entry size near the 500-word mark, as requested, I&apos;ve had to write next to nothing. As a result, I&apos;ve learned - you guessed it - next to nothing.
		I did learn how to attach object to one another though.
	</p>
	<h3>What surprised me or caused me to wonder?</h3>
	<p>
		The biggest surprise was finding that the mouse controls were included in the boilerplate code we started with.
		It made obsolete all of the object attachments I&apos;d made, but also allowed me to apply the knowledge I&apos;d gained by having me attach things directly to the camera to prevent them from moving in the scene when the camera moved.
	</p>
	<h3>What happened that felt particularly challenging? Why was it challenging to me?</h3>
	<p>
		My main challenge this week was the restriction on my word count.
		When I don&apos;t write, I don&apos;t learn, which made it very difficult to complete the assignment using the new material that I hadn&apos;t retained after reading.
		I can&apos;t learn by reading alone.
	</p>
	<h3>What skills and knowledge do I recognize that I am gaining?</h3>
	<p>
		I suppose the main skill I improved this week was making use of existing library functionality.
		I was going to try to write code to implement mouse-based controls, and being a complicated task that I&apos;ve never done anything even similar to, and only having a week to do it, I would have failed.
		But using the library&apos;s existing functionality, I just had to tweak my code to accommodate the way the library&apos;s solution differed from what I needed to shoehorn it into working perfectly.
	</p>
	<h3>What am I realizing about myself as a learner?</h3>
	<p>
		I realise that I work through both problems and new information by writing about them, and when I don&apos;t write extensively about things I&apos;m already struggling with, everything becomes immensely more difficult.
	</p>
	<h3>In what ways am I able to apply the ideas and concepts gained to my own experience?</h3>
	<p>
		I suppose the most-useful takeaway from this week would be to look at problems from different angles.
		My initial plan was to leave the camera stationary and move the model, but moving the camera instead turned out to be easier.
	</p>
</section>
<section id="Unit6">
	<h2>Unit 6</h2>
	<h3>Describe what you did.</h3>
	<p>
		I read chapter twelve of <a href="https://www.cs.csustan.edu/~rsc/NSF/Notes.pdf">Notes.pdf</a>, participated in the discussion assignment, and built a model of the earth and moon.
	</p>
	<h3>Describe your reactions to what you did.</h3>
	<p>
		My main reaction was to seeing the &quot;textures&quot; we were asked to use.
		I spent hours fixing them to be somewhat okay, but they still weren&apos;t working textures.
		Thankfully, the professor offered real textures to use.
	</p>
	<h3>Describe any feedback you received or any specific interactions you had.</h3>
	<p>
		The main feedback this week was from the <a href="https://y.st./en/coursework/CS4406/Assignment_~4_for_CS4406_Computer_Graphics.xhtml">Unit 4 assignment</a>.
		One student suggested how better to display animation, while another was impressed with the use of a &quot;data:&quot;-schem $a[URI] to get around JavaScript&apos;s inability to properly load images from other domains.
	</p>
	<h3>Describe your feelings and attitudes.</h3>
	<p>
		Last week, I started out the assignment by building a flawed model that required features I didn&apos;t actually need for the final model (though I left them in the final model to save effort).
		Because of last week&apos;s unnecessary extra struggles, this week&apos;s assignment took almost zero effort, aside from the hours spent fixing the &quot;textures&quot; themselves.
		However, I feel like whoever chose the &quot;textures&quot; for this week&apos;s assignment had never in their life actually textured spheres.
		Even having only done it once, I could tell as soon as I looked at the images that they would never work for the job.
		Furthermore, I don&apos;t think the assignment got reviewed by someone that actually knew what they were doing after the textures were chosen.
		The assignment was probably written, then someone who didn&apos;t know what they were doing was later sent to find textures.
		I&apos;m glad that at least the professor was able to see how bad they were and offer working ones.
	</p>
	<h3>Describe what you learned.</h3>
	<p>
		I learned about five types of animation.
		That was most of what I took away from this week, because it didn&apos;t count toward my word limit, so I could write in more detail, and thus learn it more effectively.
	</p>
	<h3>What surprised me or caused me to wonder?</h3>
	<p>
		I wonder who chose those &quot;textures&quot; and what they were thinking.
		I also wonder how in the world we&apos;re supposed to be working with images in JavaScript without a proper environment that allows uploads.
		I know how to use &quot;data:&quot;-schem $a[URI]s myself, but that hasn&apos;t been taught in any course at this school I&apos;ve take, so how are the other students supposed to make this environment work?
		We were given zero instructions as to what to do on this front.
	</p>
	<h3>What happened that felt particularly challenging? Why was it challenging to me?</h3>
	<p>
		My biggest challenge is the limit on my word count.
		Without writing much, I don&apos;t learn much, which makes it hard to complete the work.
	</p>
	<h3>What skills and knowledge do I recognize that I am gaining?</h3>
	<p>
		I learned how to stretch images from one shape to another by hand.
		It&apos;s a pain, and I don&apos;t know when I&apos;ll use this skill, but it&apos;s not a skill I had before this week.
	</p>
	<h3>What am I realizing about myself as a learner?</h3>
	<p>
		As always when I&apos;m not allowed to write much, I&apos;m becoming painfully aware of just how hard it is for me to learn when I can&apos;t write about it.
	</p>
	<h3>In what ways am I able to apply the ideas and concepts gained to my own experience?</h3>
	<p>
		I&apos;ve been thinking of using image-stretching to create a nice avatar, but that&apos;s the only think I can think of that might use what I&apos;ve learned this week for.
	</p>
</section>
<section id="Unit7">
	<h2>Unit 7</h2>
	<h3>Describe what you did.</h3>
	<p>
		I read chapter fourteen of <a href="https://www.cs.csustan.edu/~rsc/NSF/Notes.pdf">Notes.pdf</a> and worked with a broken <code>three.js</code> script to build a model of a function that showed the graph of a pointy, cone-like function.
	</p>
	<h3>Describe your reactions to what you did.</h3>
	<p>
		I found on day zero that the <code>three.js</code> $a[API] had broken on me, and even undid all my work on past assignments.
		On day one, I posted a hacky workaround, but I was frustrated, and when I reached out for help, I got none.
		On day five, another student posted another hacky solution.
		And on day six - the final day - another student posted the actual solution to the problem, which they&apos;d managed to find.
		We students were left on our own to deal with an $a[API] we weren&apos;t overly familiar with suddenly breaking on us for no good reason though.
		We got no help as to what to do, and next term&apos;s students are going to be working with the pre-broken $a[API].
	</p>
	<h3>Describe any feedback you received or any specific interactions you had.</h3>
	<p>
		You said that I don&apos;t need to try to keep my count at exactly 500 words, so that helps a bit with phrasing.
		I can use better sentences because I don&apos;t have to consider word count so closely.
		It doesn&apos;t fix the overall problem though: when I don&apos;t write much, I don&apos;t learn much.
		With a subject as hard as this one, I need a couple thousand words, or I&apos;m not going to be able to learn, remember, and understand what&apos;s going on.
		Something anywhere close to 500 really isn&apos;t going to help me learn anything.
	</p>
	<h3>Describe your feelings and attitudes.</h3>
	<p>
		My feelings are mainly those of exasperation from dealing with the combined problems of the broken $a[API] hindering my programming and the word count hindering my learning.
	</p>
	<h3>Describe what you learned.</h3>
	<p>
		I tried to learn to use <code>THREE.ParametricGeometry()</code>, but that was one of the parts of the $a[API] that was broken.
		I spent all my time this week trying to make my submission work despite the broken $a[API], and didn&apos;t actually have time to learn anything new at all.
	</p>
	<h3>What surprised me or caused me to wonder?</h3>
	<p>
		The sudden breaking of the $a[API] surprised me, and I wonder why it isn&apos;t self-contained.
		If it were self-contained, it wouldn&apos;t break when a new release was made, but would instead continue to function, just without the new features of the update.
	</p>
	<h3>What happened that felt particularly challenging? Why was it challenging to me?</h3>
	<p>
		The $a[API] broke on me.
		It broke on all of us students.
		Without a working $a[API], how were we supposed to program?
	</p>
	<h3>What skills and knowledge do I recognize that I am gaining?</h3>
	<p>
		This week was spent trying to get around broken $a[API] features.
		I didn&apos;t have any time to develop any new skills this time.
	</p>
	<h3>What am I realizing about myself as a learner?</h3>
	<p>
		I realise that as a learner, I don&apos;t learn much when I&apos;m not allowed to write much.
		I need to write extensively so I can crystallise my thoughts, retain knowledge, and work through problems.
	</p>
	<h3>In what ways am I able to apply the ideas and concepts gained to my own experience?</h3>
	<p>
		I was too busy trying to find my way around a broken $a[API] to gain anything new to apply to my life.
		I suppose debugging applies to my life outside of school, though this isn&apos;t some new concept.
		I always write buggy code an have to repair it.
		Though usually, it&apos;s my own code that&apos;s broken, so I can fix it, where this code wasn&apos;t mine, and was read-only so I couldn&apos;t fix it.
		I just had to work around the bugs to cobble something together that half worked.
	</p>
</section>
<section id="Unit8">
	<h2>Unit 8</h2>
	<h3>Describe what you did.</h3>
	<p>
		I read <a href="https://cg.inf.h-bonn-rhein-sieg.de/wp-content/uploads/2009/04/introductiontoraytracing.pdf">Microsoft Word - RT-KUCH.DOC - introductiontoraytracing.pdf</a>, <a href="https://my.eng.utah.edu/~cs6965/papers/a1-slusallek.pdf">a1-slusallek.pdf</a>, and chapter fourteen of <a href="https://www.cs.csustan.edu/~rsc/NSF/Notes.pdf">Notes.pdf</a>, graded work from last week, participated in the discussion assignment, and took the final exam for the course.
	</p>
	<h3>Describe your reactions to what you did.</h3>
	<p>
		This was an easy week.
		I wasn&apos;t able to absorb much of the material due to the word limit, but the final exam turned out not to be very difficult, and we had no programming assignment this week.
		I&apos;m sure I missed several of the questions on the exame, but I think I got most of them right.
	</p>
	<h3>Describe any feedback you received or any specific interactions you had.</h3>
	<p>
		The main feedback I got was from last week&apos;s <a href="https://y.st./en/coursework/CS4406/#Unit7">learning journal entry</a>.
		You said that programming is an exercise of the brain.
		This is exactly why I&apos;ve been struggling so much in this course.
		I exercise my brain through my writing.
		When I&apos;m hit with a limit to how much I can write, I don&apos;t get the warm-up exercise my brain needs, and I can&apos;t work through what I&apos;ve just read very well.
		Then the harder exercise of the programming assignment overwhelms me.
		When I&apos;m not allowed to write much, I don&apos;t learn much, and 500 words isn&apos;t enough for me to learn hardly anything.
		I don&apos;t do well when I&apos;m not allowed to write a lot more than that.
	</p>
	<h3>Describe your feelings and attitudes.</h3>
	<p>
		Working with <code>three.js</code> has been an incredibly taxing experience.
		All in all, the problems boiled down to a combination of a lack of sufficient documentation, remote $a[API]s that broke on you while you were trying to complete your assignments, and general inadequacies of the base language, JavaScript.
		I hope that if I ever have to work with three-dimensional graphics again, I don&apos;t have to do it through a framework a cumbersome to work with as <code>three.js</code>.
		This course has been a source of multiple headaches this terms, and I&apos;m glad that it&apos;s finally over with.
	</p>
	<h3>Describe what you learned.</h3>
	<p>
		This week, I learned the high-level differences between ray-casting and ray-tracing.
	</p>
	<h3>What surprised me or caused me to wonder?</h3>
	<p>
		I was surprised that the final exam was mostly easy, considering how much I&apos;ve been struggling in this course as well as how little of the material I&apos;ve been able to remember due to the word limit on my learning journal entries.
	</p>
	<h3>What happened that felt particularly challenging? Why was it challenging to me?</h3>
	<p>
		The only real challenge this week was getting the discussion assignment post submitted within the first couple days.
		I had to get through most of the material for the week within two days to make that happen and meet my deadline.
		After that, the rest of the week was easy, as I didn&apos;t have much material left to read.
	</p>
	<h3>What skills and knowledge do I recognize that I am gaining?</h3>
	<p>
		This week wasn&apos;t about skill, as we didn&apos;t actually put anything into practice.
		I can&apos;t remember any of the material this week aside form some of the stuff on ray-casting and ray-tracing, so I guess that would be the knowledge I&apos;ve taken from this week.
	</p>
	<h3>What am I realizing about myself as a learner?</h3>
	<p>
		I realise the same thing I always realise: when I&apos;m not allowed to write much, I don&apos;t learn much.
		I need to write to exercise my brain and retain what I&apos;m reading.
		If I was allowed to write, say, a 200- to 300-word learning journal entry, I would have learned a lot more this week.
	</p>
	<h3>In what ways am I able to apply the ideas and concepts gained to my own experience?</h3>
	<p>
		As far as I can tell, not of this can be applied to my life.
		Ray-casting and ray-tracing are interesting on a theoretical level, but in practice, I don&apos;t work with three-dimensional graphics, so this knowledge doesn&apos;t help me.
	</p>
</section>
END
);
